Contrasting procedural and event-driven programs
Understanding the difference between procedural and event-driven programs is one of the most important requirements of learning how to write OpenEdge applications. The program you have written so far is a simple but good example of a procedural program. It executes basically from the top down. When it comes to a statement to RUN another procedure, such as the calcDays internal procedure, then it initiates that procedure, passes parameters into it, and when it gets to the end, returns any output parameters, and that’s the end of it. There’s no code placed off to the side for events initiated by the user. The programmer determines the procedure flow. A program doesn’t prompt the user for input until it’s ready to. The user has little ability to move around in the interface flexibly. This is typical of a character interface application. The simple diagram in Figure 5–2 illustrates top-down or hierarchy programming.
When the procedure mainproc.p runs a.p, and then a.p runs a1.p, then mainproc.p, a.p, and a1.p are in memory. When a1.p returns, its context is removed and it goes out of scope. When a.p returns, its context is deleted. And only then can the code run b.p, which might run b1.p. The thread of execution goes right up and down through this hierarchy of called procedures.
By contrast, your sample procedure from this chapter is a simple but very good example of an event-driven procedure, as illustrated in Figure 5–3. Most of the code the interpreter encounters as it initializes the procedure doesn’t actually get executed. It just sets up bodies of code to run when the user requests it.
